VRRP is a protocol described in Internet Engineering Task Force (IETF) document RFC 3768. The purpose of VRRP is to increase the availability of a default gateway servicing hosts on the same subnet. VRRP allows two or more physical routers to act as a single virtual router comprising a primary router actively routing data packet traffic and one or more backup routers, one of which will replace the role of the primary router should it fail. Currently, there is a need to update VRRP for use with Internet Protocol version 6 (IPv6). For example, IETF draft-ietf-vrrp-unified-spec proposes such an updated version of VRRP.
VRRP is typically used by Enterprises to provide redundancy at some major strategic data center that requires continuous operation to serve its clients. In many cases, Enterprises build their data centers with two different backbone connections, each connection via a separate physical router. When implementing VRRP, the Enterprise will configure the two physical routers as a virtual router. Each of the physical routers will therefore have a respective connection to the backbone network and each will be connected to the data center's local area network (LAN), also referred to as a VRRP subnet subsequent to VRRP implementation. The VRRP subnet provides a connection between the two physical routers, hereinafter referred to as VRRP routers.
According to routing protocols such as border gateway protocol (BGP) described in IETF document RFC4271, a route metric/cost is associated with the output side of each router interface. This cost is configurable by the system administrator and it always has a default value. The lower the cost, the more likely the interface is to be used to forward data traffic.
By design, VRRP and routing protocols do not interact with each other. This means that a routing protocol will be unaware of the state of a VRRP router interface, also referred to herein as a VRRP interface. That is, the routing protocol will be unaware whether the VRRP router is a primary or a backup VRRP router. When advertising a Local Interface route of the VRRP subnet, from both the primary and backup routers, the same default cost is used.
The problem is that the static route metric/cost can result in routes to the VRRP subnet having equal cost, or in many configurations the backup VRRP router ends up being the best next hop to the VRRP subnet. While neither case is desirable, the former can be particularly problematic for applications sensitive to unequal multipath delays if equal cost multipath (ECMP) routing is enabled, since traffic from a remote host to any host in the VRRP subnet can take different paths. IETF documents RFC2991 and RFC2992 address issues and techniques of ECMP routing.